This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Location services based on the location of mobile devices are becoming increasingly widespread. Assistance data for assisted navigation systems, such as GNSS, have been specified and standardized for cellular systems, e.g., global positioning systems (GPS), European Galileo, and Russian Global Navigation Satellite System (GLONASS). An exemplary GNSS can comprise a network of satellites that broadcasts navigation signals including time and distance data. GNSS receivers pick up these broadcasted navigation signals and calculate a precise global location based thereon. Other examples of GNSS include, but are not limited to, satellite-based augmentation systems (SBAS), local area augmentation systems (LAAS), quasi-zenith satellite systems (QZSS), and hybrid receivers.
The delivery of such assistance data can be built on top of cellular system-specific control plane protocols including, e.g., the radio research location services protocol (RRLP) for GSM networks, the radio resource control (RRC) layer of layer 3 in wideband code division multiple access (WCDMA) networks, and IS-801 for Code Division Multiple Access (CDMA) networks. It should be noted that assistance data as described herein, can refer to GNSS assistance containing, but not limited to, navigation models, time assistance, reference location, atmosphere models, differential corrections, sensor assistance and acquisition assistance. The assistance data can also include e.g. position information, high-accuracy position, information, multi-frequency multi-GNSS measurement data, computationally-generated measurements, sensor measurements, route information and waypoint information.
Common features exist in a majority, if not all of the protocols including, but not limited to those described above for delivering assistance data. However, when differences arise, a terminal's software must either have an adaptation layer for the relevant protocols or is limited to supporting only some, but not all of the protocols. Additionally, whenever a new cellular system (e.g., networks using worldwide interoperability for microwave access (WiMAX) technology or a standard such as the long term evolution (LTE) standard, a successor to GSM), is brought into use, a terminal must adapt to the specifics of that system/network as well.
In response to the above, the Open Mobile Alliance (OMA) has defined a user plane protocol referred to as secure user plane location (SUPL) 1.0. SUPL employs user plane data bearers for transferring location assistance information such as GPS assistance data, as described above, for carrying positioning technology-related protocols between terminal, e.g., a mobile communication device and its operating network. SUPL is intended to be an alternative and, at the same time, a complement to the existing standards based on signaling in the mobile network control plane. SUPL assumes that a mobile or other network can establish a data bearer connection between a terminal and some type of location server. The use of a user plane protocol is especially appealing in the case of Internet Protocol (IP) networks where the data bearer is by nature, available.
In 2008, both the 3rd Generation Partnership Project (3GPP) and the Open Mobile Alliance (OMA) standardization bodies have accelerated efforts to standardize GNSS assistance for various satellite systems that are as of yet, unsupported in the respective standards specifications. Current support in the standards has been implemented for GPS and Galileo only thus far. In a next phase, support is to be extended to modernized GPS, GLONASS, QZSS, and a number of SBASs. Each of the aforementioned systems has certain characteristics and/or features unique to those systems which need special attention with regard to integrating such features to assistance specifications.
The current GLONASS system (e.g., GLONASS and GLONASS-M satellites) uses a Frequency Division Multiple Access (FDMA) scheme to separate satellite transmissions from each other. Due to the use of FDMA, none of the visible satellites transmit on exactly the same frequency band, where each satellite is transmitting on its own nominal frequency. However, the same nominal transmission frequency can be allocated to another satellite, although when doing so, the satellites should be located at opposite sides of an orbit so as not to interference with any other satellites on the same frequency. The GLONASS transmission frequencies and used frequency bands are described in the GLONASS Interface Control Document (ICD), while currently employed satellite-frequency allocation is described at, e.g., http://www.glonass-ianc.rsa.ru. Furthermore, it should be noted that GLONASS satellites that are launched after 2005 will employ the following frequency channels: k=(−7 . . . +6) from the range −7 through 13 (i.e., 21 values).
It is envisioned that the next generation of GLONASS system will utilize a CDMA scheme similar to that utilized by GPS to separate the satellites. Thus, in a next generation GLONASS system, each satellite will transmit on exactly the same nominal frequency, but use a different spreading code (pseudorandom code). The next generation GLONASS satellites are referred to as GLONASS-K satellites.
Additionally, GLONASS satellites are located on three orbits referred to as I, II and III. Each of these three orbits can nominally populate at most, 8 satellites, giving a maximum nominal constellation of 3×8, i.e., 24 satellites. In the future, the GLONASS-K constellation may be modified to support a greater number of satellites, e.g., up to 30 satellites.
The GPS constellation as well is undergoing modernization, where new frequencies and signals are being allocated for open service and military use. Additionally, new data content is being added to conventional navigation data improve performance and provide new services. These upcoming changes are documented and publicly available in form of ICDs.
However, GPS is an existing system and its services are already in wide use thereby preventing an “overnight” process of modernization. For example, one challenge for the US Department of Defense (DoD) in terms of GPS modernization is the deployment of new satellites with the new signals and services that are to gradually replace the existing generation of satellites. The size of the GPS constellation cannot exceed 32 satellites, and with 31 satellites currently in the constellation, coupled with a rather long lifetime for the satellites, replacing the entire GPS constellation with next generation satellites can take as long as 10-15 years. Moreover, GPS modernization does not merely include the introduction of one totally new generation of satellites, but rather also includes considering a number of parallel generations of satellites listed in Table 1. As can be seen, the supported open service signals (and frequencies) differ greatly from generation to generation.
TABLE 1GPS Satellite GenerationsGenerationOpen Service SignalsStatusGPS IIRLink 1 Coarse AcquisitionDeployedsignals (L1CA)GPS IIR-ML1CA and Link 23 launched + 5 to comeCivil/open service signals(L2C)GPS IIFL1CA, L2C and Link 5First launch expected inopen service signals (L5)2009GPS IIIL1CA, L2C, L5 and LinkUnder planning1 Civil (modernized L1open service) signals(L1C)
Because of the FDMA scheme, there is no need to allocate different spreading codes to the satellites. However, all GLONASS satellites utilize the same pseudorandom code for signal modulation. Contrary to GPS, where each satellite has its own pseudorandom code identified by a pseudorandom code number (PRN), GLONASS signals do not possess an unambiguous physical signature to identify the satellites. Additionally and as indicated above, transmission frequency in GLONASS can be shared among more than one satellite. This lack of unambiguous identity can be problematic from an Assistance Data Service perspective because unambiguously linking certain pieces of assistance data to specific satellites when PRN or Frequency Index cannot be utilized may be necessary.
Furthermore, GPS modernization can be problematic from an assisted GNSS (A-GNSS) point of view. Because of the GPS satellite modernization process described above, the number of supported signals may be different with respect to different satellites. Further still, support may suddenly change for a certain satellite (i.e., satellite identification) after it has been replaced by a newer version. From a terminal point of view, it would be advantageous to know a priori which signals the satellite is supporting in order to avoid wasting power on the acquisition of non-existing (non-supported) signals. In an opposite scenario, knowledge regarding which signals a satellite supports would afford the opportunity to search for a best possible signal for a certain satellite. As GPS modernization is taking place gradually, scenarios could arise where certain satellites, e.g., those with the latest L1C signals giving the best acquisition performance, are visible with satellites only supporting L1CA. Additionally, current A-GNSS (A-GPS) standards do not allow for indicating to a terminal, what generation a satellite belongs to or which signals are supported by a satellite. It should be noted that SBAS and QZSS satellites may also have different signal and frequency support amongst satellites in the same system.
The Radio Technical Commission for Maritime Services (RTCM) specification (RTCM v3.0, Feb. 10, 2004) uses GLONASS Orbit Slot Indices for Satellite Identification. Although GLONASS satellites are divided into three planes, the Orbit Slot index is continuous from orbit to orbit making it possible to identify the satellites. RTCM messages also carry the GLONASS Frequency Index. As described at, e.g., http://www.glonass-ianc.rsa.ru, GLONASS satellites are indexed as follows: satellites in Orbit I are indexed from 1 to 8; satellites in Orbit II are indexed from 9 to 16; and satellites in Orbit III are indexed from 17 to 24. However, RTCM does not provide an indexing/identification solution for different GPS generations.
The National Maritime Electronics Association (NMEA) 0183 version 3.01 (Jan. 1, 2002) specifications describe a definition for GLONASS satellite indices in NMEA messages. The NMEA 0183 utilizes Slot Numbers for satellite identification with a 64+ satellite slot number. Slot numbers 1 through 24 are utilized for a full GLONASS constellation of 24 satellites which in turn provides a range of 65 through 88 for use with GLONASS satellite identification numbers in the NMEA messages. Slot numbers 89 through 96 are available if the slot numbers above 24 are allocated to on-orbit spares. However, like RTCM, NMEA does not provide an indexing/identification solution for different GPS generations.
Current A-GPS/A-GNSS standards utilize a satellite identification based on PRN and do not support GLONASS satellites. The satellite identification in, e.g., GSM RRLP specifications, is a 6-bit parameter capable of including, e.g., the 6-bit PRN of Galileo satellites. Moreover, information elements (IEs) in Assistance Data specifications are organized hierarchically so that satellite system specific IEs are all referenced by a common GNSS identification (GNSS ID), as for example, in GPS, Galileo, GLONASS, etc.